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Internet Printing Protocol/1.1: Encoding and Transport 
Abstract 


The Internet Printing Protocol (IPP) is an application-level protocol 
for distributed printing using Internet tools and technologies. This 
document defines the rules for encoding IPP operations, attributes, 
and values into the Internet MIME media type called 
"application/ipp". It also defines the rules for transporting a 
message body whose Content-Type is "application/ipp" over HTTP and/or 
HTTPS. The IPP data model and operation semantics are described in 
"Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011). 


This document obsoletes RFCs 2910 and 3382. 
Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8010. 
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1. Introduction 


This document contains the rules for encoding IPP operations and 
describes two layers: the transport layer and the operation layer. 


The transport layer consists of an HTTP request and response. All 
IPP implementations support HTTP/1.1, the relevant parts of which are 
described in the following RFCs: 


o Hypertext Transfer Protocol (HITP/1.1): Message Syntax and Routing 
[RFC7230] 


o Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content 


[RFC7231] 


o Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests 


[RFC7232] 


o Hypertext Transfer Protocol (HTTP/1.1): Caching [RFC7234] 


o Hypertext Transfer Protocol (HTTP/1.1): Authentication [RFC7235] 


o The ’Basic’ HTTP Authentication Scheme [RFC7617] 
o HTTP Digest Access Authentication [RFC7616] 


IPP implementations can support HTTIP/2, which is described in the 
following RFCs: 


o Hypertext Transfer Protocol Version 2 (HTTP/2) [RFC7540] 
o HPACK - Header Compression for HTTP/2 [RFC7541] 


This document specifies the HTTP headers that an IPP implementation 
supports. 


The operation layer consists of a message body in an HTTP request or 
response. The "Internet Printing Protocol/1.1: Model and Semantics" 
document [RFC8011] and subsequent extensions (collectively known as 
the IPP Model) define the semantics of such a message body and the 
supported values. This document specifies the encoding of an IPP 
request and response message. 


Sweet & McDonald Standards Track [Page 4] 


RFC 8010 IPP/1.1: Encoding and Transport January 2017 


2. Conventions Used in This Document 
2.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.2. Printing Terminology 


Client: Initiator of outgoing IPP session requests and sender of 
outgoing IPP operation requests (Hypertext Transfer Protocol -- 
HTTP/1.1 [RFC7230] User Agent). 


Document: An object created and managed by a Printer that contains 
description, processing, and status information. A Document object 
may have attached data and is bound to a single Job. 


‘ipp’ URI: An IPP URI as defined in [RFC3510]. 
‘ipps’ URI: An IPPS URI as defined in [RFC7472]. 


Job: An object created and managed by a Printer that contains 
description, processing, and status information. The Job also 
contains zero or more Document objects. 


Logical Device: A print server, software service, or gateway that 
processes Jobs and either forwards or stores the processed Job or 
uses one or more Physical Devices to render output. 


Model: The semantics of operations, attributes, values, and status- 
codes used in the Internet Printing Protocol as defined in the 
Internet Printing Protocol/1.1: Model and Semantics document 
[RFC8011] and subsequent extensions. 


Output Device: A single Logical or Physical Device. 


Physical Device: A hardware implementation of an endpoint device, 
e.g., a marking engine, a fax modem, etc. 


Printer: Listener for incoming IPP session requests and receiver of 
incoming IPP operation requests (Hypertext Transfer Protocol -- 
HTTP/1.1 [RFC7230] Server) that represents one or more Physical 
Devices or a Logical Device. 
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2.3. Abbreviations 
ABNF: Augmented Backus-Naur Form [RFC5234] 
ASCII: American Standard Code for Information Interchange [RFC20] 
HTTP: Hypertext Transfer Protocol [RFC7230] 
HTTPS: HTTP over TLS [RFC2818] 
IANA: Internet Assigned Numbers Authority 
IEEE: Institute of Electrical and Electronics Engineers 
IESG: Internet Engineering Steering Group 
IPP: Internet Printing Protocol (this document and [PWG5100.12]) 
ISTO: IEEE Industry Standards and Technology Organization 
LPD: Line Printer Daemon Protocol [RFC1179] 
PWG: IEEE-ISTO Printer Working Group 
RFC: Request for Comments 
TCP: Transmission Control Protocol [RFC793] 
TLS: Transport Layer Security [RFC5246] 
URI: Uniform Resource Identifier [RFC3986] 
URL: Uniform Resource Locator [RFC3986] 
UTF-8: Unicode Transformation Format - 8-bit [RFC3629] 
3. Encoding of the Operation Layer 
The operation layer is the message body part of the HTTP request or 
response and it MUST contain a single IPP operation request or IPP 
operation response. Each request or response consists of a sequence 
of values and attribute groups. Attribute groups consist of a 
sequence of attributes each of which is a name and value. Names and 
values are ultimately sequences of octets. 
The encoding consists of octets as the most primitive type. There 


are several types built from octets, but three important types are 
integers, character strings, and octet strings, on which most other 
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data types are built. Every character string in this encoding MUST 
be a sequence of characters where the characters are associated with 
some charset [RFC2978] and some natural language. A character string 
MUST be in "reading order" with the first character in the value 
(according to reading order) being the first character in the 
encoding. A character string whose associated charset is US-ASCII 
and whose associated natural language is US English is henceforth 
called a US-ASCII-STRING. A character string whose associated 
charset and natural language are specified in a request or response 
as described in the Model is henceforth called a LOCALIZED-STRING. 

An octet string MUST be in "Model order" with the first octet in the 
value (according to the Model order) being the first octet in the 
encoding. Every integer in this encoding MUST be encoded as a signed 
integer using two’s-complement binary encoding with big-endian format 
(also known as "network order" and "most significant byte first"). 
The number of octets for an integer MUST be 1, 2, or 4, depending on 
usage in the protocol. A one-octet integer, henceforth called a 
SIGNED-BYTE, is used for the version-number and tag fields. A two- 
byte integer, henceforth called a SIGNED-SHORT, is used for the 
operation-id, status-code, and length fields. A four-byte integer, 
henceforth called a SIGNED-INTEGER, is used for value fields and the 
request—id. 


The following two sections present the encoding of the operation 
layer in two ways: 


o informally through pictures and description 


o formally through Augmented Backus-Naur Form (ABNF), as specified 
by RFC 5234 [RFC5234] 


An operation request or response MUST use the encoding described in 
these two sections. 
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3.1. Picture of the Encoding 
3.1.1. Request and Response 


An operation request or response is encoded as follows: 


| version-number | 2 bytes - required 
| operation-id (request) 
| or | 2 bytes - required 
| status-code (response) 


| request-id | 4 bytes - required 
anaes attribute-group | bytes ~ 0 or more 
je end-of-attributes-tag | lbyte - required 
; Ce a A a a Hebe A a q bytes - optional 


Figure 1: IPP Message Format 


The first three fields in the above diagram contain the value of 
attributes described in Section 4.1.1 of the Model and Semantics 
document [RFC8011]. 


The fourth field is the "attribute-group" field, and it occurs 0 or 
more times. Each "attribute-group" field represents a single group 
of attributes, such as an Operation Attributes group or a Job 
Attributes group (see the Model). The Model specifies the required 
attribute groups and their order for each operation request and 
response. 


The "end-of-attributes-tag" field is always present, even when the 


"data" is not present. The Model specifies whether the "data" field 
is present for each operation request and response. 
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3.1.2. Attribute Group 


Each "attribute-group" field is encoded as follows: 


Figure 2: Attribute Group Encoding 
An "attribute-group" field contains zero or more "attribute" fields. 


Note that the values of the "begin-attribute-group-tag" field and the 
"end-of-attributes-tag" field are called "delimiter-tags". 


3.1.3. Attribute 


An "attribute" field is encoded as follows: 


Figure 3: Attribute Encoding 


When an attribute is single valued (e.g., "copies" with a value of 
10) or multi-valued with one value (e.g., "sides-supported" with just 
the value ’one-sided’), it is encoded with just an "attribute-with- 
one-value" field. When an attribute is multi-valued with n values 
(e.g., “Sides-supported" with the values ’one-sided’ and ’two-sided- 
long-edge’), it is encoded with an "attribute-with-one-value" field 
followed by n-1 "“additional-value" fields. 
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3.1.4. Attribute-with-one-value 


Each “attribute-with-one-value" field is encoded as follows: 


| value-tag | 1 byte 
bo name-length (value isu) | 2 bytes 
eo oe name | u byte’ 
fc value-length (value is v) | 2 bytes 
a value | v bytes 


Figure 4: Single Value Attribute Encoding 
An "attribute-with-one-value" field is encoded with five subfields: 


o The "value-tag" field specifies the attribute syntax, e.g., 0x44 
for the attribute syntax 'keyword’. 


O The "name-length" field specifies the length of the "name" field 
in bytes, e.g., u in the above diagram or 15 for the name "sides- 
supported". 


O The "name" field contains the textual name of the attribute, e.g., 
"sides-supported". 


o The "value-length" field specifies the length of the "value" field 
in bytes, e.g., v in the above diagram or 9 for the (keyword) 


value one-sided’. 


o The "value" field contains the value of the attribute, e.g., the 
textual value ’one-sided’. 
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Sil S78 


Additional-value 


Each “additional-value" field is encoded as follows: 


An 


Sweet 


value-tag | pa 
anna ey) eee 
Te S o 
e eee a a w bytes 


Figure 5: Additional Attribute Value Encoding 
"additional-value" is encoded with four subfields: 


The "value-tag" field specifies the attribute syntax, e.g., 0x44 
for the attribute syntax 'keyword'’. 


The "name-length" field has the value of 0 in order to signify 
that it is an "additional-value". The value of the "name-length" 
field distinguishes an "additional-value" field ("name-length" is 
0) from an "attribute-with-one-value" field ("name-length" is not 
0). 


The "value-length" field specifies the length of the "value" field 
in bytes, e.g., w in the above diagram or 19 for the (keyword) 


value ’two-sided-long-edge’. 


The "value" field contains the value of the attribute, e.g., the 
textual value ’two-sided-long-edge’. 
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3.1.6. Collection Attribute 


Collection attributes create a named group containing related 
"member" attributes. The "“attribute-with-one-value" field fora 
collection attribute is encoded as follows: 


| value-tag (value is 0x34) | 1 byte 

ic: 3 name-length (value isu) | 2 bytes 

jo eee name 0 | u bytes 

D value-length (value is 0x0000) | 2 bytes 
ee menber-attribute | q bytes |-0 or more 
bo end-value-tag (value is 0x37) | 1 byte 

| end-name-length (value is 0x0000) | bytes 


| end-value-length (value is 0x0000) | 


N 
o 

< 
ct 
0) 
0) 


Figure 6: Collection Attribute Encoding 
Collection attribute is encoded with eight subfields: 


o The "value-tag" field specifies the start attribute syntax: 0x34 
for the attribute syntax ’begCollection’. 


o The "name-length" field specifies the length of the "name" field 
in bytes, e.g., u in the above diagram or 9 for the name "media-— 
col". Additional collection attribute values use a name length of 
0x0000. 


o The "name" field contains the textual name of the attribute, e.g., 
"media-col". 


o The "value-length" field specifies a length of 0x0000. 


o The "member-attribute" field contains member attributes encoded as 
defined in Section 3.1.7. 


o The "“end-value-tag" field specifies the end attribute syntax: 0x37 
for the attribute syntax ’endCollection’. 


o The "end-name-length" field specifies a length of 0x0000. 
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o The "“end-value-length" field specifies a length of 0x0000. 
3.1.7. Member Attributes 


Each "member-attribute" field is encoded as follows: 


| value-tag (value is 0x4a) | aan 
ao ot oi ane 
iene eae ae 
bane ee eee 
oe menber-value-tag | byte 
i ee ee a eres 
o e neter va ee aeaa | bytes 
ee —— a 


Figure 7: Member Attribute Encoding 
A "member-attribute" is encoded with eight subfields: 


o The "value-tag" field specifies 0x4a for the attribute syntax 
‘memberAttrName’. 


o The "name-length" field has the value of 0 in order to signify 
that it is a "member-attribute" contained in the collection. 


o The "value-length" field specifies the length of the "value" 
in bytes, e.g., w in the above diagram or 10 for the member 


attribute name ’/media-type’. Additional member attribute values 


are specified using a value length of 0. 


o The "value" field contains the name of the member attribute, 
the textual value ’/media-type’. 


o The "member-value-tag" field specifies the attribute syntax for 


the member attribute, e.g., 0x44 for the attribute syntax 
‘keyword’. 
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36s 


The second "name-length" field has the value of 0 in order to 
signify that it is a "member-attribute" contained in the 
collection. 


The "member-value-length" field specifies the length of the member 
attribute value, e.g., x in the above diagram or 10 for the value 


‘stationery’. 


The "member-value" field contains the value of the attribute, 
e.g., the textual value ’stationery’. 


Alternative Picture of the Encoding of a Request or a Response 


From the standpoint of a parser that performs an action based on a 
"tag" value, the encoding consists of: 


version-number | 2 bytes - required 


operation-id (request) | 
or | 2 bytes - required 
status-code (response) | 


request-id | 4 bytes - required 
tag (delimiter-tag or value-tag) | 1 byte | 
SSSS SSR RSS a eases oases |-0 or more 
empty or rest of attribute | x bytes | 
end-of-attributes-tag | 1 byte - required 
data | y bytes - optional 


Figure 8: Encoding Based on Value Tags 


The following shows what fields the parser would expect after each 
type of "tag": 


(0) 


"begin-attribute-group-tag": expect zero or more "attribute" 
fields 


"value-tag": expect the remainder of an "attribute-with-one-value" 
or an "additional-value" 


"end-of-attributes-tag": expect that "attribute" fields are 
complete and there is optional "data" 
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3.2. Syntax of En 
The ABNF [RFC52 


ipp-message 
ipp-request = 


ipp-response = 


version-number 
major-version-n 
minor-version-n 


operation-id = 
status-—code 
request-—id 


attribute-group 
attribute 
attribute-with—- 


additional-valu 


name-length 
name 

value-length = 
value 
data = 


zero-name-lengt 
value-tag 

begin-attribute 
end-of-attribut 


SIGNED-BYTE 
SIGNED-SHORT 
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coding 


January 2017 


34] syntax for an IPP message is shown in Figure 9. 


= ipp-request / ipp-response 


version-number operation-id request-—id 
*attribute-group end-of-attributes-tag data 


version-number status-code request-—id 


*attribute-group end-of-attributes-tag data 


= major-version-number minor-version-number 


umber = SIGNED-BYTE 


umber = SIGNED-BYTE 

SIGNED-SHORT ; mapping from model 
SIGNED-SHORT ; mapping from model 
SIGNED-INTEGER ; whose value is > 0 


= begin-attribute-group-tag *attribute 
= attribute-with-one-value *additional-value 
one-value = value-tag name-length name 
value-length value 
e = value-tag zero-name-length 
value-length value 


OCTET-STRING 
OCTET-STRING 


SIGNED-INTEGER 
DIGIT 

LALPHA 

BYTE 
OCTET-STRING 


Sweet & McDonald 


h = $x00.00 

= $x10-ff 
-group-tag = %x00-02 / 
es-tag = $x03 
= BYTE 
= 2BYTE 
= 4BYTE 
= $x30-39 Om 
= Sx61-7A phan 
= $x00-ff 
= *BYTE 


Figure 9: ABNF of IPP 


= SIGNED-SHORT ; number of octets of ’name’ 
LALPHA *( LALPHA / DIGIT / "-" / "" / ™,™ ) 
SIGNED-SHORT ; number of octets of /value’ 


; name-length of 0 


; see 

%x04-0f ; see 
; tag 
; see 

Lo wou 

to non 


Message Format 


Standards Track 


Section 3.5.2 
Section 3.5.1 
of 3 

Section 3.5.1 
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Figure 10 defines additional terms that are referenced in this 
document and provides an alternate grouping of the delimiter tags. 


delimiter-tag = begin-attribute-group-tag / ; see Section 3.5.1 
end-of-attributes-tag 
begin-attribute-group-tag = %x00 / operation-attributes-tag / 
job-attributes-tag / printer-attributes-tag / 
unsupported-attributes-tag / future-group-tags 


operation-attributes-tag = $x01 ; tag of 1 
job-attributes-tag = $x02 ; tag of 2 
end-of-attributes-tag = $x03 ; tag of 3 
printer-attributes-tag = $x04 ; tag of 4 
unsupported-attributes-tag = %x05 ; tag of 5 


future-group-tags %x06-0f ; future extensions 
Figure 10: ABNF for Attribute Group Tags 
3.3. Attribute-group 
Each "attribute-group" field MUST be encoded with the "begin- 


attribute-group-tag" field followed by zero or more "attribute" sub- 
fields. 
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Table 1 maps the Model group name to value of the "begin-attribute- 
group-tag" field: 


4+—---------------- +-------------------- -- -- - 5 5 5 5 = + 
| Model Document | "begin-attribute-group-tag" field values | 
| Group | | 
4+---------------- +-------------------- -- -- - 5 5 = + 
| Operation | "operations-attributes-tag" 

| Attributes | | 
4+---------------- +------------------------ = = = 5 = + 
| Job Template | "job-attributes-tag" 

| Attributes | | 
4+---------------- +------------------------- = 5 5 = + 
| Job Object | "job-attributes-tag" 

| Attributes | | 
4+---------------- +------------------------ - 5 5 = + 
| Unsupported | "unsupported-attributes-tag" 

| Attributes | | 
4+---------------- +-------------------- -- -- 5 5 = + 
| Requested | (Get-Job-Attributes) "job-attributes-tag" | 
| Attributes | | 
4+—---------------- +------------------------ $5 5 = + 
| Requested | (Get-Printer-Attributes)"printer-attributes-tag" | 
| Attributes | | 
4+---------------- +------------------------ 5 5 = + 
| Document | in a special position at the end of the message | 
| Content | as described in Section 3.1.1. 

4+---------------- +------------------------- = 5 = + 


Table 1: Group Values 


For each operation request and response, the Model prescribes the 
required and optional attribute groups, along with their order. 
Within each attribute group, the Model prescribes the required and 
optional attributes, along with their order. 


When the Model requires an attribute group in a request or response 
and the attribute group contains zero attributes, a request or 
response SHOULD encode the attribute group with the "begin-attribute- 
group-tag" field followed by zero "attribute" fields. For example, 
if the Client requests a single unsupported attribute with the Get- 
Printer-Attributes operation, the Printer MUST return no "attribute" 
fields, and it SHOULD return a "begin-attribute-group-tag" field for 
the Printer Attributes group. The Unsupported Attributes group is 
not such an example. According to the Model, the Unsupported 
Attributes group SHOULD be present only if the Unsupported Attributes 
group contains at least one attribute. 
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A receiver of a request MUST be able to process the following as 
equivalent empty attribute groups: 


a. A "begin-attribute-group-tag" field with zero following 
"attribute" fields. 


b. A missing, but expected, "begin-attribute-group-tag" field. 


When the Model requires a sequence of an unknown number of attribute 
groups, each of the same type, the encoding MUST contain one "begin- 
attribute-group-tag" field for each attribute group, even when an 
"attribute-group" field contains zero "attribute" sub-fields. For 
example, the Get-Jobs operation may return zero attributes for some 
Jobs and not others. The "begin-attribute-group-tag" field followed 
by zero "attribute" fields tells the recipient that there is a Job in 
queue for which no information is available except that it is in the 
queue. 


3.4. Required Parameters 


Some operation elements are called parameters in the Model. They 
MUST be encoded in a special position and they MUST NOT appear as 
operation attributes. These parameters are described in the 
subsections below. 


334.1. "version-number" 


The "version-number" field consists of a major and minor version- 
number, each of which is represented by a SIGNED-BYTE. The major 
version-number is the first byte of the encoding and the minor 
version-number is the second byte of the encoding. The protocol 
described in [RFC8011] has a major version-number of 1 (0x01) anda 


minor version-number of 1 (0x01). The ABNF for these two bytes is 
$x01.01. 


Note: See Section 9 for more information on the "version-number" 
field and IPP version numbers. 


3.4.2. “"“operation-id" 
The "operation-id" field contains an operation-id value as defined in 


the Model. The value is encoded as a SIGNED-SHORT and is located in 
the third and fourth bytes of the encoding of an operation request. 
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34.53% "status-—code" 
The "status-code" field contains a status-code value as defined in 
the Model. The value is encoded as a SIGNED-SHORT and is located in 


the third and fourth bytes of the encoding of an operation response. 


If an IPP status-code is returned, then the HTTP status-code MUST be 


200 (OK). With any other HTTP status-code value, the HTTP response 
MUST NOT contain an IPP message body, and thus no IPP status-code is 
returned. 

3.4.4. “"request-id" 


The "request-id" field contains the request-id value as defined in 
the Model. The value is encoded as a SIGNED-INTEGER and is located 
in the fifth through eighth bytes of the encoding. 

3.5. Tags 


There are two kinds of tags: 


o delimiter tags: delimit major sections of the protocol, namely 
attribute groups and data 


o value tags: specify the type of each attribute value 
Tags are part of the IANA IPP registry [IANA-IPP] 
3.5.1. "delimiter-tag" Values 
Table 2 specifies the values for the delimiter tags defined in this 


document. These tags are registered, along with tags defined in 
other documents, in the "Attribute Group Tags" registry. 


+----------------- 4+—------------------------------ + 
| Tag Value (Hex) | Meaning | 
+----------------- 4+------------------------------ + 
| 0x00 | Reserved 
| 0x01 | "operation-attributes-tag" | 
0x02 "job-attributes-tag" 
0x03 "end-of-attributes-tag" 
| 0x04 | "printer-attributes-tag" 
| 0x05 | "unsupported-attributes-tag" | 
+—----------------- +—------------------------------ + 


Table 2: "delimiter-tag" Values 
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When a "begin-attribute-group-tag" field occurs in the protocol, it 
means that zero or more following attributes up to the next group tag 
are attributes belonging to the attribute group specified by the 
value of the "begin-attribute-group-tag". For example, if the value 
of "begin-attribute-group-tag" is 0x01, the following attributes are 
members of the Operations Attributes group. 


The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in 
an operation and MUST be the last "delimiter-tag". If the operation 
has a document-data group, the Document data in that group follows 
the "end-of-attributes-tag". 


The order and presence of "attribute-group" fields (whose beginning 
is marked by the "begin-attribute-group-tag" subfield) for each 
operation request and each operation response MUST be that defined in 
the Model. 


A Printer MUST treat a "delimiter-tag" (values from 0x00 through 
Ox0f) differently from a "value-tag" (values from 0x10 through Oxff) 
so that the Printer knows there is an entire attribute group as 
opposed to a single value. 


3.5.2. "value-tag" Values 
The remaining tables show values for the "value-tag" field, which is 


the first octet of an attribute. The "value-tag" field specifies the 
type of the value of the attribute. 


Table 3 specifies the "out-of-band" values for the "value-tag" field 


defined in this document. These tags are registered, along with tags 
defined in other documents, in the "Out-of-Band Attribute Value Tags" 
registry. 

+----------------- +------------- + 

| Tag Value (Hex) | Meaning | 

+----------------- +------------- + 

| 0x10 | unsupported | 

| 0x12 | unknown 

| 0x13 | no-value | 

+----------------- +------------- + 


Table 3: Out-of-Band Values 
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Table 4 specifies the integer values defined in this document for the 
"value-tag" field; they are registered in the "Attribute Syntaxes" 


registry. 

+---------------- +------------------------ - -- - - 5-5 = == + 
| Tag Value | Meaning | 
| (Hex) | | 
+---------------- +--------------------------- - $5 = + 

0x20 Unassigned integer data type (see IANA IPP 
registry) 

| 0x21 | integer | 
| 0x22 | boolean | 
| 0x23 | enum | 
| 0x24-0x2f | Unassigned integer data types (see IANA IPP | 
| | registry) | 
+---------------- +--------------------------- - $5 5 = + 


Table 4: Integer Tags 


Table 5 specifies the octetString values defined in this document for 
the "value-tag" field; they are registered in the "Attribute 
Syntaxes" registry. 


4+--------------- 4+------------------------- -- 5 5 = + 
| Tag Value | Meaning | 
| (Hex) | | 
+--------------- +------------------------- = 5 5 + 
0x30 octetString with an unspecified format 
0x31 dateTime 
| 0x32 | resolution 
| 0x33 | rangeOfInteger 
| 0x34 | begCollection 
| 0x35 | textWithLanguage 
| 0x36 | nameWithLanguage 
0x37 endCollection 
| 0x38-0x3f | Unassigned octetString data types (see IANA IPP | 
| | registry) 
+--------------- +—------------------------- -- 5-5 5 + 


Table 5: octetString Tags 
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Table 6 specifies the character-string values defined in this 
document for the "value-tag" field; they are registered in the 
"Attribute Syntaxes" registry. 


+--------------- +--------------------- - 5 $5 5 = + 
| Tag Value | Meaning | 
| (Hex) | | 
+--------------- +--------------------- - 5 = + 
0x40 Unassigned character-string data type (see IANA 
IPP registry) 
| 0x41 | textWithout Language 
| 0x42 | nameWithout Language 
| 0x43 | Unassigned character-string data type (see IANA | 
| | IPP registry) | 
| 0x44 | keyword | 
| 0x45 | uri | 
0x46 uriScheme 
| 0x47 | charset | 
| 0x48 | naturalLanguage 
| 0x49 | mimeMediaType 
| Ox4a | memberAttrName 
Ox4b-Ox5f Unassigned character-string data types (see IANA 
IPP registry) 
+--------------- t------------------ - 5 = + 


Table 6: String Tags 


Note: An attribute value always has a type, which is explicitly 
specified by its tag; one such tag value is "nameWithoutLanguage". 
An attribute’s name has an implicit type, which is keyword. 


The values 0x60-Oxff are reserved for future type definitions in 
Standards Track documents. 


The tag 0x7f is reserved for extending types beyond the 255 values 
available with a single byte. A tag value of Ox7f MUST signify that 
the first four bytes of the value field are interpreted as the tag 
value. Note this future extension doesn’t affect parsers that are 
unaware of this special tag. The tag is like any other unknown tag, 
and the value length specifies the length of a value, which contains 
a value that the parser treats atomically. Values from 0x00000000 to 
Ox3fffffff are reserved for definition in future Standards Track 
documents. The values 0x40000000 to Ox7fffffff are reserved for 
vendor extensions. 
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3.6. “"name-length" 


The "name-length" field consists of a SIGNED-SHORT and specifies the 
number of octets in the immediately following "name" field. The 
value of this field excludes the two bytes of the "name-length" 
field. For example, if the "name" field contains ’sides’, the value 
of this field is 5. 


If a "name-length" field has a value of zero, the following "name" 
field is empty and the following value is treated as an additional 
value for the attribute encoded in the nearest preceding "attribute- 
with-one-value" field. Within an attribute group, if two or more 
attributes have the same name, the attribute group is malformed (see 
[RFC8011]). The zero-length name is the only mechanism for multi- 
valued attributes. 


iS ce (Attribute) "name" 


The "name" field contains the name of an attribute. The Model 
specifies such names. 


3.8. “"value-length" 


The "value-length" field consists of a SIGNED-SHORT, which specifies 
the number of octets in the immediately following "value" field. The 
value of this field excludes the two bytes of the "value-length" 
field. For example, if the "value" field contains the keyword 
(string) value ’one-sided’, the value of this field is 9. 


For any of the types represented by binary signed integers, the 
sender MUST encode the value in exactly four octets. 


For any of the types represented by binary signed bytes, e.g., the 
boolean type, the sender MUST encode the value in exactly one octet. 


For any of the types represented by character strings, the sender 
MUST encode the value with all the characters of the string and 
without any padding characters. 


For "out-of-band" values for the "value-tag" field defined in this 
document, such as ’unsupported’, the "value-length" MUST be 0 and the 
"value" empty; the "value" has no meaning when the "value-tag" has 
one of these "out-of-band" values. For future "out-of-band" "value- 
tag" fields, the same rule holds unless the definition explicitly 
states that the "value-length" MAY be non-zero and the "value" non- 
empty 
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33/9 (Attribute) "value" 


The syntax types (specified by the "value-tag" field) and most of the 
details of the representation of attribute values are defined in the 

Model. Table 7 augments the information in the Model and defines the 
syntax types from the Model in terms of the five basic types defined 

in Section 3. The five types are US-ASCII-STRING, LOCALIZED-STRING, 

SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING. 


4+---------------------- 4-------------------------------------------- + 
| Syntax of Attribute | Encoding 
| Value | 
+---------------------- 4-------------------------------------------- + 
| textWithoutLanguage, | LOCALIZED-STRING 
| nameWithoutLanguage | | 
+---------------------- 4-------------------------------------------- + 
| textWithLanguage | OCTET-STRING consisting of four fields: a | 
| | SIGNED-SHORT, which is the number of 
| | octets in the following field; a value of | 
| | type natural-language; a SIGNED-SHORT, | 
| | which is the number of octets in the | 
| | following field; and a value of type 
textWithoutLanguage. The length of a 
| | textWithLanguage value MUST be 4 + the | 
| | value of field a + the value of field c. | 
+---------------------- 4-------------------------------------------- + 
| nameWithLanguage | OCTET-STRING consisting of four fields: a | 
| | SIGNED-SHORT, which is the number of 
octets in the following field; a value of 
| | type natural-language; a SIGNED-SHORT, | 
| | which is the number of octets in the | 
| | following field; and a value of type | 
| | nameWithoutLanguage. The length of a 
nameWithLanguage value MUST be 4 + the 
value of field a + the value of field c. 
+---------------------- 4-------------------------------------------- + 
| charset, | US-ASCII-STRING 
| naturalLanguage, | | 
| mimeMediaType, | | 
keyword, uri, and 
uriScheme 
4+---------------------- 4-------------------------------------------- + 
| boolean | SIGNED-BYTE where 0x00 is ’false’ and 0x01 | 
| | is ‘true’ | 
+---------------------- 4-------------------------------------------- + 
| 


| integer and enum a SIGNED-INTEGER 
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+ =-=- — 
| dateTime 


resolution 


| octetString 

+ =-= — 
| collection 

+ =-= iiiI 


—— + —— H — + 


+ 
| 

+ 
| 

+ 


ee ee SS a er eS SS ee ee eS eS SS ree + 


OCTET-STRING consisting of eleven octets 
whose contents are defined by 
"DateAndTime" in RFC 2579 [RFC2579] 


Sa SSS Sh ee E E Se Se + 


OCTET-STRING consisting of nine octets of 
two SIGNED-INTEGERs followed by a SIGNED- 
BYTE. The first SIGNED-INTEGER contains 
the value of cross-feed direction 
resolution. The second SIGNED-INTEGER 
contains the value of feed direction 
resolution. The SIGNED-BYTE contains the 
units value. 


Eight octets consisting of two SIGNED- 
INTEGERS. The first SIGNED-INTEGER 
contains the lower bound and the second 
SIGNED-INTEGER contains the upper bound. 


EEE E E E A ae E A EA E EA Se es fee EA Ss a Seed et + 


Encoding according to the rules for an 
attribute with more than one value. Each 
value X is encoded according to the rules 
for encoding its type. 


EEEE EEO EE eee a ee ee ee + 


OCTET-STRING 


SSeS SS Se Se ee SO Se Se ee Se SS SS Se + 


Encoding as defined in Section 3.1.6. 


i a a a ee ee ee ee er ee ee ee ee Se ee eee + 


Table 7: Attribute Value Encoding 


The attribute syntax type of the value determines its encoding and 
the value of its "value-tag". 


3.10. Data 


The "data" field MUST include any data required by the operation. 


Sweet & McDonald 
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4. Encoding of Transport Layer 


HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. 
HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol. 


The operation layer has been designed with the assumption that the 
transport layer contains the following information: 


o the target URI for the operation; and 


o the total length of the data in the operation layer, either as a 
single length or as a sequence of chunks each with a length. 


Printer implementations MUST support HTTP over the IANA-assigned 
well-known port 631 (the IPP default port), although a Printer 
implementation can support HTTP over some other port as well. 


Each HTTP operation MUST use the POST method where the request-target 
is the object target of the operation and where the "Content-Type" of 
the message body in each request and response MUST be "application/ 
ipp". The message body MUST contain the operation layer and MUST 
have the syntax described in Section 3.2, "Syntax of Encoding". A 
Client implementation MUST adhere to the rules for a Client described 
for HTTP [RFC7230]. A Printer (server) implementation MUST adhere to 
the rules for an origin server described for HTTP [RFC7230]. 


An IPP server sends a response for each request that it receives. If 
an IPP server detects an error, it MAY send a response before it has 
read the entire request. If the HTTP layer of the IPP server 
completes processing the HTTP headers successfully, it MAY send an 
intermediate response, such as "100 Continue", with no IPP data 
before sending the IPP response. A Client MUST expect such a variety 
of responses from an IPP server. For further information on HTTP, 
consult the HTTP documents [RFC7230]. 


An HTTP/1.1 server MUST support chunking for IPP requests, and an IPP 
Client MUST support chunking for IPP responses according to HTTP/1.1 
[RFC7230]. 


4.1. Printer URI, Job URI, and Job ID 
All Printer and Job objects are identified by a Uniform Resource 
Identifier (URI) [RFC3986] so that they can be persistently and 


unambiguously referenced. Jobs can also be identified by a 
combination of Printer URI and Job ID. 
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Some operation elements are encoded twice, once as the request-target 
on the HTTP request-line and a second time as a REQUIRED operation 
attribute in the application/ipp entity. These attributes are the 
target for the operation and are called "printer-uri" and "job-uri". 


Note: The target URI is included twice in an operation referencing 
the same IPP object, but the two URIs can be different. For example, 
the HTTP request-target can be relative while the IPP request URI is 
absolute. 


HTTP allows Clients to generate and send a relative URI rather than 
an absolute URI. A relative URI identifies a resource with the scope 
of the HTTP server but does not include scheme, host, or port. The 
following statements characterize how URIs are used in the mapping of 
IPP onto HTTP: 


1. Although potentially redundant, a Client MUST supply the target 
of the operation both as an operation attribute and as a URI at 
the HTTP layer. The rationale for this decision is to maintain a 
consistent set of rules for mapping "application/ipp" to possibly 
many communication layers, even where URIs are not used as the 
addressing mechanism in the transport layer. 


2. Even though these two URIs might not be literally identical (one 
being relative and the other being absolute), they MUST both 
reference the same IPP object. 


3. The URI in the HTTP layer is either relative or absolute and is 
used by the HTTP server to route the HTTP request to the correct 
resource relative to that HTTP server. 


4. Once the HTTP server resource begins to process the HTTP request, 
it can get the reference to the appropriate IPP Printer object 
from either the HTTP URI (using to the context of the HTTP server 
for relative URIs) or from the URI within the operation request; 
the choice is up to the implementation. 


5. HTTP URIs can be relative or absolute, but the target URI in the 
IPP operation attribute MUST be an absolute URI. 
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3% 


IPP URI Schemes 


The IPP URI schemes are /’ipp’ [RFC3510] and ’ipps’ [RFC7472]. 
Clients and Printers MUST support the ipp-URI value in the following 
IPP attributes: 


o Job attributes: 

* job-uri 

*  Job-printer-uri 
o Printer attributes: 

* printer-uri-supported 
o Operation attributes: 

* Job=uri 

* printer-uri 
Each of the above attributes identifies a Printer or Job. The 
ipp-URI and ipps-URI are intended as the value of the attributes in 
this list. All of these attributes have a syntax type of ’uri’, but 
there are attributes with a syntax type of /’uri’ that do not use the 


‘ipp’ scheme, e.g., "job-more-info". 


If a Printer registers its URI with a directory service, the Printer 
MUST register an ipp-URI or ipps-URI. 


When a Client sends a request, it MUST convert a target ipp-URI to a 
target http-URL (or ipps-URI to a target https-URI) for the HTTP 
layer according to the following steps: 


1. change the ’ipp’ scheme to ’http’ or ‘’ipps’ scheme to ’https’; 
and 


2. add an explicit port 631 if the ipp-URL or ipps-URL does not 
contain an explicit port. Note that port 631 is the IANA- 
assigned well-known port for the ’ipp’ and ‘ipps’ schemes. 


The Client MUST use the target http-URL or https-URL in both the HTTP 
request-line and HTTP headers, as specified by HTTP [RFC7230]. 
However, the Client MUST use the target ipp-URI or ipps-URI for the 
value of the "printer-uri" or "job-uri" operation attribute within 
the application/ipp body of the request. The server MUST use the 


Sweet & McDonald Standards Track [Page 28] 


RFC 8010 IPP/1.1: Encoding and Transport January 2017 


ipp-URI or ipps-URI for the value of the "printer-uri", "job-uri", or 
"printer-uri-supported" attributes within the application/ipp body of 
the response. 


For example, when an IPP Client sends a request directly, i.e., no 
proxy, to an ipp-URI "ipp://printer.example.com/ipp/print/myqueue", 
it opens a TCP connection to port 631 (the IPP implicit port) on the 
host "printer.example.com" and sends the following data: 


POST /ipp/print/myqueue HTTP/1.1 
Host: printer.example.com: 631 
Content-type: application/ipp 
Transfer-Encoding: chunked 


"printer-uri" 'ipp://printer.example.com/ipp/print/myqueue’ 
(encoded in application/ipp message body) 


Figure 11: Direct IPP Request 


As another example, when an IPP Client sends the same request as 
above via a proxy "myproxy.example.com", it opens a TCP connection to 
the proxy port 8080 on the proxy host "myproxy.example.com" and sends 
the following data: 


POST http://printer.example.com:631/ipp/print/myqueue HTTP/1.1 
Host: printer.example.com: 631 

Content-type: application/ipp 

Transfer-Encoding: chunked 


"printer-uri" 'ipp://printer.example.com/ipp/print/myqueue’ 
(encoded in application/ipp message body) 
Figure 12: Proxied IPP Request 


The proxy then connects to the IPP origin server with headers that 
are the same as the "no-proxy" example above. 


6. IANA Considerations 
The IANA-PRINTER-MIB [RFC3805] has been updated to reference this 
document; the current version is available from 
<http://www.iana.org>. 
See the IANA Considerations in the document "Internet Printing 


Protocol/1.1: Model and Semantics" [RFC8011] for information on IANA 
considerations for IPP extensions. IANA has updated the existing 
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‘application/ipp’ media type registration (whose contents are defined 
in Section 3 "Encoding of the Operation Layer") with the following 
information. 


Type name: application 
Subtype name: ipp 
Required parameters: N/A 
Optional parameters: N/A 


Encoding considerations: IPP requests/responses MAY contain long 
lines and ALWAYS contain binary data (for example, attribute value 
lengths). 


Security considerations: IPP requests/responses do not introduce any 
security risks not already inherent in the underlying transport 
protocols. Protocol mixed-version interworking rules in [RFC8011] as 
well as protocol-encoding rules in this document are complete and 
unambiguous. See also the security considerations in this document 
and [RFC8011]. 


Interoperability considerations: IPP requests (generated by Clients) 
and responses (generated by servers) MUST comply with all conformance 
requirements imposed by the normative specifications [RFC8011] and 
this document. Protocol-encoding rules specified in RFC 8010 are 
comprehensive so that interoperability between conforming 
implementations is guaranteed (although support for specific optional 
features is not ensured). Both the "charset" and "natural-language" 
of all IPP attribute values that are a LOCALIZED-STRING are explicit 
within IPP requests/responses (without recourse to any external 
information in HTTP, SMTP, or other message transport headers). 


Published specifications: RFCs 8010 and 8011 


Applications that use this media type: Internet Printing Protocol 
(IPP) print clients and print servers that communicate using HTTP/ 
HTTPS or other transport protocols. Messages of type "application/ 
ipp" are self-contained and transport independent, including 
"charset" and "natural-language" context for any LOCALIZED-STRING 
value. 


Fragment identifier considerations: N/A 
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Additional information: 

Deprecated alias names for this type: N/A 

Magic number(s): N/A 

File extension(s): N/A 

Macintosh file type code(s): N/A 
Person & email address to contact for further information: 

ISTO PWG IPP Workgroup <ipp@pwg.org> 
Intended usage: COMMON 
Restrictions on usage: N/A 
Author: ISTO PWG IPP Workgroup <ipp@pwg.org> 
Change controller: ISTO PWG IPP Workgroup <ipp@pwg.org> 
Provisional registration? (standards tree only): No 

7. Internationalization Considerations 
See the section on "Internationalization Considerations" in the 
document "Internet Printing Protocol/1.1: Model and Semantics" 
[RFC8011] for information on internationalization. This document 
adds no additional issues. 
8. Security Considerations 

The IPP Model and Semantics document [RFC8011] discusses high-level 
security requirements (Client Authentication, Server Authentication, 
and Operation Privacy). Client Authentication is the mechanism by 
which the Client proves its identity to the server in a secure 
manner. Server Authentication is the mechanism by which the server 
proves its identity to the Client in a secure manner. Operation 
Privacy is defined as a mechanism for protecting operations from 
eavesdropping. 
Message Integrity is addressed in the document "Internet Printing 
Protocol (IPP) over HTTPS Transport Binding and the ’ipps’ URI 
Scheme" [RFC7472]. 


8.1. Security Conformance Requirements 


This section defines the security requirements for IPP Clients and 
IPP objects. 
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8.1.1. Digest Authentication 


IPP Clients and Printers SHOULD support Digest Authentication 
[RFC7616]. Use of the Message Integrity feature (qop="auth-int") is 
OPTIONAL. 


Note: Previous versions of this specification required support for 
the MD5 algorithms; however, [RFC7616] makes SHA2-256 mandatory to 
implement and deprecates MD5, only allowing its use for backwards 
compatibility reasons. IPP implementations that support Digest 
Authentication MUST support SHA2-256 and SHOULD support MD5 for 
backwards compatibility. 


Note: The reason that IPP Clients and Printers SHOULD (rather than 
MUST) support Digest Authentication is that there is a certain class 
of Output Devices where it does not make sense. Specifically, a low- 
end device with limited ROM space and low paper throughput may not 
need Client Authentication. This class of device typically requires 
firmware designers to make trade-offs between protocols and 
functionality to arrive at the lowest-cost solution possible. 
Factored into the designer’s decisions is not just the size of the 
code, but also the testing, maintenance, usefulness, and time-to- 
market impact for each feature delivered to the customer. Forcing 
such low-end devices to provide security in order to claim IPP/1.1 
conformance would not make business sense. Print devices that have 
high-volume throughput and have available ROM space will typically 
provide support for Client Authentication that safeguards the device 
from unauthorized access because these devices are prone to a high 
loss of consumables and paper if unauthorized access occurs. 


8.1.2. Transport Layer Security (TLS) 


IPP Clients and Printers SHOULD support Transport Layer Security 
(TLS) [RFC5246] [RFC7525] for Server Authentication and Operation 
Privacy. IPP Printers MAY also support TLS for Client 
Authentication. IPP Clients and Printers MAY support Basic 
Authentication [RFC7617] for User Authentication if the channel is 
secure, e.g., IPP over HTTPS [RFC7472]. IPP Clients and Printers 
SHOULD NOT support Basic Authentication over insecure channels. 


The IPP Model and Semantics document [RFC8011] defines two Printer 
attributes ("uri-authentication-supported" and "uri-security- 
supported") that the Client can use to discover the security policy 
of a Printer. That document also outlines IPP-specific security 
considerations and is the primary reference for security implications 
with regard to the IPP itself. 
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Note: Because previous versions of this specification did not require 
TLS support, this version cannot require it for IPP/1.1. However, 
since printing often involves a great deal of sensitive or private 
information (medical reports, performance reviews, banking 
information, etc.) and network monitoring is pervasive ([RFC7258]), 
implementors are strongly encouraged to include TLS support. 


Note: Because IPP Printers typically use self-signed X.509 
certificates, IPP Clients SHOULD support Trust On First Use (defined 
in [RFC7435]) in addition to traditional X.509 certificate 
validation. 


8.2. Using IPP with TLS 


IPP uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817] 
for '’ipp’ URIs. The Client requests a secure TLS connection by using 
the HTTP "Upgrade" header while the server agrees in the HTTP 
response. The switch to TLS occurs either because the server grants 
the Client’s request to upgrade to TLS or a server asks to switch to 
TLS in its response. Secure communication begins with a server’s 
response to switch to TLS. 


IPP uses the "HTTPS: HTTP over TLS" mechanism [RFC2818] for ’ipps’ 
URIs. The Client and server negotiate a secure TLS connection 
immediately and unconditionally. 


9. Interoperability with Other IPP Versions 


It is beyond the scope of this specification to mandate conformance 
with versions of IPP other than 1.1. IPP was deliberately designed, 
however, to make supporting other versions easy. IPP objects 
(Printers, Jobs, etc.) SHOULD: 


o understand any valid request whose major "version-number" is 
greater than 0; and 


o respond appropriately with a response containing the same 
"version-number" parameter value used by the Client in the request 
(if the Client-supplied "version-number" is supported) or the 
highest "version-number" supported by the Printer (if the Client- 
supplied "version-number" is not supported). 


IPP Clients SHOULD: 


o understand any valid response whose major "version-number" is 
greater than 0. 
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The "version-number" Parameter 


The following are rules regarding the "version-number" parameter (see 
Section 3.3): 


D2. 


Clients MUST send requests containing a "version-number" 
parameter with the highest supported value, e.g., ’1.1’, '2.0’, 
etc., and SHOULD try supplying alternate version numbers if they 
receive a ’server-error-version-not-—supported’ error return ina 
response. For example, if a Client sends an IPP/2.0 request that 
is rejected with the ’server-error-version-not-—supported’ error 
and an IPP/1.1 "version-number", it SHOULD retry by sending an 
IPP/1.1 request. 


IPP objects (Printers, Jobs, etc.) MUST accept requests 
containing a "version-number" parameter with a ’1.1’ value (or 
reject the request for reasons other than ’server-error-version-— 
not-supported’). 


IPP objects SHOULD either accept requests whose major version is 
greater than 0 or reject such requests with the ’server-error- 
version-not-—supported’ status-code. See Section 4.1.8 of 
[RFC8011]. 


In any case, security MUST NOT be compromised when a Client 
supplies a lower "version-number" parameter in a request. For 
example, if an IPP/2.0 conforming Printer accepts version ’1.1’ 
requests and is configured to enforce Digest Authentication, it 
MUST do the same for a version ‘1.1’ request. 


Security and URI Schemes 


The following are rules regarding security, the "version-number" 
parameter, and the URI scheme supplied in target attributes and 
responses: 


1. 


When a Client supplies a request, the "printer-uri" or "job-uri" 
target operation attribute MUST have the same scheme as that 
indicated in one of the values of the "printer-uri-supported" 
Printer attribute. 


When the Printer returns the "Jjob-printer-uri" or "job-uri" Job 
Description attributes, it SHOULD return the same scheme (’ipp’, 
‘ipps’, etc.) that the Client supplied in the "printer-uri" or 
"job-uri" target operation attributes in the Get-—Job-Attributes 
or Get-Jobs request, rather than the scheme used when the Job was 
created. However, when a Client requests Job attributes using 
the Get-Job-Attributes or Get-Jobs operations, the Jobs and Job 
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attributes that the Printer returns depends on: (1) the security 
in effect when the Job was created, (2) the security in effect in 
the query request, and (3) the security policy in force. 


The Printer MUST enforce its security and privacy policies based 


on the 


owner of the IPP object and the URI scheme and/or 


credentials supplied by the Client in the current request. 


Changes since RFC 2910 


The following changes have been made since the publication of 


RFC 2910: 

o Added references to current IPP extension specifications. 

o Added optional support for HTTP/2. 

o Added collection attribute syntax from RFC 3382. 

o Fixed typographical errors. 

o Now reference TLS/1.2 and no longer mandate the TLS/1.0 MTI 
ciphersuites. 

o Updated all references. 

o Updated document organization to follow current style. 

o Updated example ipp: URIs to follow guidelines in RFC 7472. 

o Updated version compatibility for all versions of IPP. 

o Updated HTTP Digest Authentication to optional for Clients. 

o Removed references to (Experimental) IPP/1.0 and usage of 


http:/https: URLs. 
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A.1. Print-Job Request 


Encoding and Transport 


January 2017 


The following is an example of a Print-Job request with "Jjob-name", 


"copies", and "sides" 


attribute is set to ’true’ 


specified. 


The "ipp-attribute- 
so that the print request will fail if the 


fidelity" 


"copies" or the "sides" attribute is not supported or their values 


are not supported. 
Octets 


0x0101 
0x0002 
0x00000001 
0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 


0x001b 
attributes-natural-language 


0x0005 

en-us 

0x45 

0x000b 

printer-uri 

0x002c 
ipp://printer.example.com/ipp/ 
print/pinetree 

0x42 


0x0008 

job-name 

0x0006 

foobar 

0x22 

0x0016 
ipp-attribute-fidelity 


0x0001 


0x01 
0x02 


Sweet & McDonald 


Symbolic Value 


1.1 

Print—Job 

1 

start operation- 
attributes 
charset type 


attributes-charset 
UTF-8 
natural-language 


type 


attributes-natural- 
language 


en-US 
uri type 


printer-uri 
printer pinetree 


nameWithoutLanguage 
type 


job-name 


foobar 
boolean type 


ipp-attribute- 
fidelity 


true 
start job-attributes 


Standards Track 


Protocol field 


version-number 
operation-id 
request-id 
operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


value-tag 


name-length 
name 
value-length 
value 
value-tag 
name-length 
name 


value-length 


value 
job-attributes- 
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0x21 
0x0006 
copies 
0x0004 
0x00000014 
0x44 
0x0005 
sides 
0x0013 
two-sided-long-edge 
0x03 


SVPDP os 


IPP/1.1: Encoding and Transport 


integer type 
copies 


20 
keyword type 


sides 


two-sided-long-edge 


end-of-attributes 


<PDF Document> 


Print—Job Response (Successful) 


January 2017 


tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
value 
end-of- 
attributes-tag 
data 


Here is an example of a successful Print-—Job response to the previous 


Print—Job request. 


attributes and their supplied values. 


"successful-ok’. 
Octets 


0x0101 
0x0000 
0x00000001 
0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 


0x001b 
attributes-natural-language 


0x0005 
en-us 
0x41 


0x000e 
status-message 
0x000d 
successful-ok 
0x02 


Symbolic Value 


Wei 
successful-ok 
t 


start operation- 


attributes 
charset type 


attributes-charset 


UTF-8 


natural-language 


type 


attributes- 


natural-language 


en-US 


textWithoutLanguag 


e type 
status-message 


successful-ok 
start job- 


Standards Track 


The Printer supported the "copies" and "sides" 
The status-code returned is 


Protocol field 


version-number 
status-code 
request-id 
operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
value-tag 


name-length 
name 
value-length 
value 
job-attributes- 
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attributes 

0x21 integer 

0x0006 

job-id job-id 

0x0004 

147 147 

0x45 uri type 

0x0007 

job-uri job-uri 

0x0030 

ipp://printer.example.com/ipp/pr job 147 on 

int/pinetree/147 pinetree 

0x23 enum type 

0x0009 

job-state job-state 

0x0004 

0x0003 pending 

0x03 


A. 


3. 


Print-Job Response 


end-of-attributes 


(Failure) 


January 2017 


tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


value-tag 
name-length 
name 
value-length 
value 

end-of- 
attributes-tag 


Here is an example of an unsuccessful Print-Job response to the 


previous Print-Job request. 


It fails because, in this case, 


the 


Printer does not support the "sides" attribute and because the value 


720’ 
is created, 


attribute is returned. 
attributes-—or-values-—not-—supported’ 


Octets 


0x0101 


0x040b 


0x00000001 
0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 

0x001b 


Sweet & McDonald 


for the "copies" attribute is not supported. 
and neither a "job-id" nor a "job-uri" operation 
The error code returned is 
(0x040b) . 


Symbolic Value 


client-error-attributes-or- 
values-—not-—supported 


1 


start operation-attributes 


charset type 


attributes-charset 


UTE-8 


natural-language type 


Standards Track 


Therefore, 


no Job 


'client-error- 


Protocol 
field 


version- 
number 
status-code 


request-id 
operation- 
attributes 
tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
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attributes-natural-language attributes-natural-language name 


0x0005 

en-us 

0x41 

0x000e 
status-message 
0x002f 


client-error-attributes-or- 


values-not-supported 


0x05 


0x21 
0x0006 
copies 
0x0004 
0x00000014 
0x10 
0x0005 
sides 
0x0000 
0x03 


.4. Print-Job Response 


en-US 


textWithoutLanguage type 


status-message 


client-error-attributes-or- 
values-not-supported 


start unsupported- 
attributes 


integer type 
copies 


20 
unsupported (type) 


sides 


end-of-attributes 


(Success with Attributes Ignored) 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


unsupported- 
attributes 
tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
end-of- 
attributes- 
tag 


Here is an example of a successful Print-Job response to a Print-Job 


request like the previous Print-Job request, 
"ipp-attribute-fidelity" 


even though, in this case, 


attribute nor the value 


is 


'20’ 


' false’. 


except that the value of 
The print request succeeds, 


the Printer supports neither the "sides" 


for the "copies" attribute. 


Therefore, 


a Job is created and both a "job-id" and a "job-uri" operation 


attribute are returned. 
in an Unsupported Attributes group. 
' successful-ok-ignored-or-substituted-attributes’ 


Octets 


0x0101 
0x0001 


0x00000001 
0x01 


0x47 
0x0012 
attributes-charset 


Sweet & McDonald 


Symbolic Value 


cel 


successful-ok-ignored-or- 
substituted-attributes 


1 


start operation-attributes 


charset type 


attributes-charset 


Standards Track 


The unsupported attributes are also returned 
The error code returned is 
(0x0001). 


Protocol field 


version-number 
status-—code 


request-—id 
operation- 
attributes-tag 
value-tag 
name-length 
name 


[Page 43] 


RFC 8010 


IPP/1.1: 


0x0005 

utf-8 

0x48 

0x001b 
attributes-natural- 
language 

0x0005 

en-us 

0x41 

0x000e 

status-message 

0x002f 
successful-ok-ignored-or- 
substituted-attributes 
0x05 


0x21 
0x0006 
copies 
0x0004 
0x00000014 
0x10 
0x0005 
sides 
0x0000 
0x02 


0x21 

0x0006 

job-id 

0x0004 

147 

0x45 

0x0007 

job-uri 

0x0030 
ipp://printer.example.com/ 
ipp/print/pinetree/147 
0x23 

0x0009 

job-state 

0x0004 

0x0003 

0x03 
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UTF-8 
natural-language type 


attributes-natural-language 


en-US 
textWithoutLanguage type 


status-message 
successful-ok-ignored-or- 
substituted-attributes 
start unsupported- 
attributes 

integer type 


copies 


20 
unsupported 


(type) 
sides 

start job-attributes 
integer 

job-id 


147 
uri type 


job-uri 

job 147 on pinetree 
enum type 
job-state 


pending 
end-of-attributes 
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value-length 
value 
value-tag 
name-length 
name 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


unsupported- 
attributes tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
job- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


value-tag 
name-length 
name 
value-length 
value 

end-of- 
attributes-tag 
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The following is an example of Print-URI request with "copies" and 


"jJob-name" parameters: 


Octets 


0x0101 
0x0003 
0x00000001 
0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 


0x001b 


attributes-natural-language 


0x0005 
en-us 

0x45 

0x000b 
printer-uri 
0x002c 


ipp://printer.example.com/ipp/ 


print/pinetree 
0x45 

0x000c 
document-uri 
0x0019 


ftp://foo.example.com/foo 


0x42 


0x0008 
job-name 
0x0006 
foobar 
0x02 


0x21 

0x0006 
copies 
0x0004 


Sweet & McDonald 


Symbolic Value 
Esl 

Print-URI 

pi 

start operation- 


attributes 
charset type 


attributes-charset 
UTF-8 
natural-language 


type 


attributes-natural- 
language 


en-US 
uri type 


printer-uri 

printer pinetree 

uri type 
document-uri 
ftp://foo.example.co 


m/foo 
nameWithoutLanguage 


type 
job-name 


foobar 
start job-attributes 


integer type 


copies 


Standards Track 


Protocol field 


version-number 
operation-id 
request-—id 
operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


value-tag 
name-length 
name 
value-length 
value 


value-tag 


name-length 
name 
value-length 
value 
job-attributes- 
tag 

value-tag 
name-length 
name 
value-length 


[Page 45] 


RFC 8010 


0x00000001 
0x03 
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value 
end-of- 
attributes-tag 


The following is an example of Create-Job request with no parameters 


and no attributes: 


Octets 


0x0101 
0x0005 
0x00000001 
0x01 


0x47 
0x0012 


attributes-charset 


0x0005 
utf-8 
0x48 


0x001b 


attributes-natural-language 


0x0005 
en-us 

0x45 

0x000b 
printer-uri 
0x002c 


ipp://printer.example.com/ipp/ 


print/pinetree 


0x03 


Symbolic Value 


Ii 

Create-Job 

1 

start operation- 
attributes 
charset type 


attributes-charset 


UTF-8 
natural-language 
type 


attributes-natural- 


language 


en-US 
uri type 


printer-uri 
printer pinetree 


end-of-attributes 


A.7. Create-Job Request with Collection Attributes 


Protocol field 


version-number 
operation-id 
request-—id 
operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


end-of- 
attributes-tag 


The following is an example of Create-Job request with the "media- 


col" collection attribute 


[PWG5100.3] with the value 


"media- 


size={x-dimension=21000 y-dimension=29700} media-type=’ stationery’": 


Octets 
0x0101 


0x0005 
0x00000001 


Sweet & McDonald 


S 


1 


ymbolic Value 


ai 


Create-Job 


1 


Standards Track 


Protocol field 
version-number 


operation-id 
request-id 
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0x01 


0x47 
0x0012 


attributes-charset 


0x0005 
utf-8 
0x48 


0x001b 


attributes-natural-language 


0x0005 
en-us 

0x45 

0x000b 
printer-uri 
0x002c 


ipp://printer.example.com/ipp/ 


print/pinetree 
0x34 

0x0009 
media-col 
0x0000 

Ox4a 

0x0000 

0x000a 
media-size 


0x34 
0x0000 
0x0000 


Ox4a 

0x0000 
0x000b 
x-dimension 


0x21 
0x0000 
0x0004 


0x00005208 
Ox4a 

0x0000 
0x000b 
y-dimension 


Sweet & McDonald 


Encoding and Transport 


start operation- 
attributes 
charset type 


attributes-charset 


UTF-8 
natural-language 
type 


attributes-natural- 


language 


en-US 
uri type 


printer-uri 
printer pinetree 


begCollection 
9 

media-col 

0 
memberAttrName 
(0) 

10 

media-size 


begCollection 
0 
0 


memberAttrName 
0 

11 

x-dimension 


integer 
0 
4 


21000 
memberAttrName 
0 

11 

y-dimension 


Standards Track 
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operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
value-tag 
name-length 
name 
value-length 
value 


value-tag 
name-length 
name 
value-length 
value-tag 
name-length 
value-length 
value (member- 
name) 
member-value-tag 
name-length 
member-value- 
length 
value-tag 
name-length 
value-length 
value (member- 
name) 
member-value-tag 
name-length 
member-value- 
length 
member-value 
value-tag 
name-length 
value-length 
value (member- 
name) 
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0x21 
0x0000 
0x0004 


0x00007404 
0x37 
0x0000 
0x0000 
Ox4a 
0x0000 
0x000a 
media-type 


0x44 
0x0000 
0x000a 


stationery 
0x37 
0x0000 
0x0000 
0x03 


Get-Jobs Request 


The following is an example of Get-—Jobs request with 


no attributes: 


Octets 


0x0101 
0x000a 
0x0000007b 
0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 


0x001b 


attributes-natural-language 


0x0005 
en-us 


Sweet & McDonald 
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integer 
0 
4 


29700 
endCollection 
0 

0 
memberAttrName 
0 

10 

media-type 


keyword 
0 
10 


stationery 
endCollection 

0 

0 
end-of-attributes 


Symbolic Value 


1.1 

Get-Jobs 

123 

start operation- 
attributes 
charset type 


attributes-charset 
UTF-8 


natural-language 
type 


attributes-natural- 


language 


en-US 
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member-value-tag 
name-length 
member-value- 
length 
member-value 
end-value-tag 
end-name-length 
end-value-length 
value-tag 
name-length 
value-length 
value (member- 
name) 
member-value-tag 
name-length 
member-value- 
length 
member-value 
end-value-tag 
end-name-length 
end-value-length 
end-of- 
attributes-tag 


parameters but 


Protocol field 


version-number 
operation-id 
request-—id 
operation- 
attributes-tag 
value-tag 
name-length 
name 
value-length 
value 
value-tag 


name-length 
name 


value-length 
value 
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0x45 

0x000b 
printer-uri 
0x002c 


ipp://printer.example.com/ipp/ 


print/pinetree 
0x21 

0x0005 

limit 

0x0004 
0x00000032 

0x44 

0x0014 
requested-attributes 
0x0006 

job-id 

0x44 

0x0000 

0x0008 

job-name 

0x44 

0x0000 

Ox000f 
document-format 
0x03 


Get-Jobs Response 


IPP/1.1: 


uri type 


printer-uri 


integer type 
limit 


50 
keyword type 


requested-attributes 


job-id 
keyword type 


additional value 


job-name 
keyword type 


additional value 


document-format 
end-of-attributes 
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value-tag 
name-length 
name 
value-length 
value 


value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
name 
value-length 
value 
value-tag 
name-length 
value-length 
value 
value-tag 
name-length 
value-length 
value 
end-of- 
attributes-tag 


The following is an example of a Get-Jobs response from a previous 
The Printer returns no information about 


request with three Jobs. 


the second Job 


Octets 


0x0101 
0x0000 
0x0000007b 


0x01 


0x47 

0x0012 
attributes-charset 
0x0005 

utf-8 

0x48 

0x001b 


Sweet & McDonald 


(because of security reasons): 


Symbolic Value 
HaT 


successful-ok 
123 


start operation- 
attributes 
charset type 


attributes-charset 


UTF-8 
natural-language type 


Standards Track 


Protocol field 


version-number 
status-code 
request-id 
back) 
operation-attributes- 
tag 

value-tag 

name-length 

name 

value-length 

value 

value-tag 

name-length 


(echoed 
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attributes-natural- 
language 

0x0005 

en-us 

0x41 


0x000e 
status-message 
0x000d 
successful-ok 
0x02 


0x21 
0x0006 
job-id 
0x0004 
147 
0x36 
0x0008 
job-name 
0x000c 
0x0005 
fr-ca 
0x0003 
fou 
0x02 


0x02 


0x21 
0x0006 
job-id 
0x0004 
148 

0x36 
0x0008 
job-name 
0x0012 
0x0005 
de-CH 
0x0009 
isch guet 
0x03 


Sweet & McDonald 


IPP/1.1: 


attributes-natural- 
language 


en-US 
textWithoutLanguage 
type 


status-message 
successful-ok 

start job-attributes 
(1st object) 
integer type 

job-id 


147 
nameWithLanguage 


job-name 


fr-CA 

fou 

start job-attributes 
(2nd object) 

start job-attributes 
(3rd object) 

integer type 

job-id 


149 
nameWithLanguage 


job-name 


de-CH 


isch guet 
end-of-attributes 
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name 


value-length 
value 
value-tag 


name-length 

name 

value-length 

value 
job-attributes-tag 


value-tag 
name-length 

name 
value-length 
value 

value-tag 
name-length 

name 
value-length 
sub-value-length 
value 
sub-value-length 
name 
job-attributes-tag 


job-attributes-tag 


value-tag 
name-length 

name 
value-length 
value 

value-tag 
name-length 

name 
value-length 
sub-value-length 
value 
sub-value-length 
name 
end-of-attributes-tag 
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